home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP030793.ARJ / 03-07-93.TPC
Text File  |  1993-03-07  |  32KB  |  937 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       03-03-93 22:57:00
  6. From       Norbert Igl
  7. To         Dj Murdoch
  8. Subject    Functions Returning Strings
  9.  
  10.  
  11.  
  12. Hello Dj!
  13.  
  14. One of these days, Dj Murdoch wrote to Wilbert van Leijen:
  15.  
  16.  DM>   sp := StrPtr(Paramstr(1));
  17.  
  18.                   ^^  hmmmmm.....
  19.  
  20.  DM>   Saved := 'Parameter one: '+sp^; { This fails, and messes up Sp^. }
  21.  
  22.   typecasting a function...hmmmm
  23.  
  24. --- GoldEd 2.40p/FD2.02/FastEcho
  25.  * Origin: mother's finest. (:-)  (2:2402/300.3)
  26.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:30:44
  27.  
  28. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  29.  
  30. Conference 4
  31. Date       03-03-93 23:07:00
  32. From       Norbert Igl
  33. To         All
  34. Subject    Fast Fourier Transformation...
  35.  
  36.  
  37.  
  38. Hello All!
  39.  
  40.   I'm searching for a quick FFT and inverse FFT ( in PAS or BASM )
  41.   for limiting the frequences in sound-samples.
  42.  
  43.   Anyone ?
  44.  
  45.  
  46. Norbert
  47.  
  48. --- GoldEd 2.40p/FD2.02/FastEcho
  49.  * Origin: May the source be with you...  (2:2402/300.3)
  50.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:30:44
  51.  
  52. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  53.  
  54. Conference 4
  55. Date       03-03-93 17:24:00
  56. From       Dj Murdoch
  57. To         Hans Siemons
  58. Subject    Re: source code included...
  59.  
  60.   HS> The first thing is negotiable with the original author, 
  61.  HS> the second thing is not. My license agreement states that 
  62.  HS> I never release source with code from Borland's RTL in it.
  63.  
  64. That may in fact be negotiable.  One of the packages I've released (TPFORT)
  65. requires some code from the Object Professional library.  I originally wrote
  66. it to use compilation directives to switch between using OPro (so that owners
  67. of OPro could recompile it) and including some code that I extracted from
  68. OPro but didn't distribute.  The latter meant that the compiled units didn't
  69. Use OPro units, so anybody at all could link them into their programs, but
  70. only I could recompile it in that form.
  71.  
  72. This eventually became too much trouble, and I contacted TurboPower Software.
  73.  They graciously allowed me to include the OPro extract with every copy that
  74. I distributed, at no charge.  I included a note thanking them, and it may
  75. well be that this advertising has brought them extra business; I certainly
  76. hope so.
  77.  
  78. I know that Borland is a much bigger company than TurboPower, so may be less
  79. likely to be willing to respond to special requests like that.  But it's worth
  80. a try. 
  81.  
  82. --- Msg V3.2
  83.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  84.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:30:45
  85.  
  86. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  87.  
  88. Conference 4
  89. Date       03-01-93 16:56:00
  90. From       Dj Murdoch
  91. To         Chris Priede
  92. Subject    Re: .TPU and .OBJ files
  93.  
  94.   
  95.  CP>         BTW, someone should write a program for disassembling TPUs to 
  96.  
  97. TP
  98.  CP> 6.0+ compatible assembly source (BASM). While decompiling to Pascal
  99.  CP> source is practically impossible, this shouldn't be very difficult --
  100.  CP> tools like INTERFAC and TPU? already do most of the necessary work. 
  101. The
  102.  CP> output could then be compiled with other versions of TP. Anyone 
  103. looking
  104.  CP> for a project idea?
  105.  
  106. Unfortunately, BASM and .OBJ files can't call any routines from the System 
  107.  
  108. unit, so to do this you'd need to provide alternates for all those routines
  109.  - possible, but really not very easy.
  110.  
  111.  
  112. --- Msg V3.2
  113.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  114.  
  115. --- RyPacker v2.5a
  116.  * Origin: RyBBS HomeBase  `Home of RyBBS!'  (414)-962-1098 (1:154/333)
  117.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:31:39
  118.  
  119. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  120.  
  121. Conference 4
  122. Date       03-01-93 17:02:00
  123. From       Dj Murdoch
  124. To         Jason Duke
  125. Subject    Re: Editing big code... {$I}?
  126.  
  127.   JD> Do most of you move segments of code that you never change 
  128.  JD> to other files and then insert them with the {$I} command? 
  129.  
  130. I almost never use $I.  If something is needed in several places, I put it 
  131.  
  132. in its own unit.
  133.  
  134.  JD>  Or do you just suffer the annoyance of hitting 
  135.  JD> pageup/down twenty times every time you want to move from 
  136.  JD> your CONSTANT definitions to the code you are working on?  
  137.  JD> I am considering moving some parts of my code to other 
  138.  JD> files for this reason... But I'm wondering what other programmers do. 
  139.  
  140.  ?
  141.  
  142. Just open the same file twice in the IDE, and you can see two parts of it. 
  143.  
  144.  
  145.  
  146. --- Msg V3.2
  147.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  148.  
  149. --- RyPacker v2.5a
  150.  * Origin: RyBBS HomeBase  `Home of RyBBS!'  (414)-962-1098 (1:154/333)
  151.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:31:39
  152.  
  153. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  154.  
  155. Conference 4
  156. Date       03-01-93 17:04:00
  157. From       Dj Murdoch
  158. To         Jason Duke
  159. Subject    Re: SIZES of variables, etc...
  160.  
  161.   JD> I have a few questions.  If I set something up to use 
  162.  JD> constant A and it "recalls" this constant 20 times, is it 
  163.  JD> faster than actually typing the constant in where it is 
  164.  JD> needed?  
  165.  
  166. It's just about identical in execution, but easier to maintain.  Many 
  167. constants in programs should be named so that your program is easier to 
  168. modify later. 
  169.  
  170.  JD> Also, does the length of a variable name affect 
  171.  JD> the size of the compiled file?  
  172.  
  173. No.  As long as you don't include debugging information with your program, 
  174.  
  175. the name you use has no effect whatsoever on the program.  (As long as you 
  176.  
  177. don't step on another name, of course. :-) 
  178.  
  179.  JD> Is it faster to call a 
  180.  JD> procedure 20 times or to type it in twenty times (I mean 
  181.  JD> does it run any faster, not does it take longer to type it 
  182.  JD> in)... 
  183.  
  184. It's generally faster to have twenty copies of the procedure and avoid the 
  185.  
  186. procedure call, but not always.  Most machines these days have cached 
  187. memory, so if programs are small and stay in the cache, they'll run faster.
  188.   Of course, if you have to type the routine 20 times, it'll be a nightmare
  189.  to maintain.  Use inline procedures instead.
  190.  
  191. --- Msg V3.2
  192.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  193.  
  194. --- RyPacker v2.5a
  195.  * Origin: RyBBS HomeBase  `Home of RyBBS!'  (414)-962-1098 (1:154/333)
  196.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:31:40
  197.  
  198. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  199.  
  200. Conference 4
  201. Date       03-01-93 17:13:00
  202. From       Dj Murdoch
  203. To         Travis Linton
  204. Subject    Re: documentation
  205.  
  206.   TL> Is there anyone out there who has documentation for 
  207.  TL> Borland Turbo Pascal 6 or 7 on disk.  I'm too low on money 
  208.  TL> at the moment to buy the book.  Also does anyone know how 
  209.  TL> to import TheDraw files into a prg and get them to show properly. 
  210. Thanks.
  211.  
  212. This sounds very much as though you have a pirated copy of TP/BP.  I don't 
  213.  
  214. really care if you do or not, but please don't post requests that sound 
  215. like attempted theft in this echo.  
  216.  
  217. To others:  
  218.  
  219. Please do not reply to posts like this, either positively or negatively.  
  220.  
  221. If you want to give TL a lecture on the ethics of pirating software, DO IT 
  222.  
  223. BY NETMAIL. 
  224.  
  225. Duncan Murdoch
  226. PASCAL Moderator
  227.  
  228.  
  229. --- Msg V3.2
  230.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  231.  
  232. --- RyPacker v2.5a
  233.  * Origin: RyBBS HomeBase  `Home of RyBBS!'  (414)-962-1098 (1:154/333)
  234.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:31:40
  235.  
  236. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  237.  
  238. Conference 4
  239. Date       03-01-93 18:30:00
  240. From       Dj Murdoch
  241. To         Benjamin Schollnick
  242. Subject    DLLs (was: rather foolish...)
  243.  
  244.   BS> After 15-20 minutes of pouring over the manuals, I can't  BS> find any
  245. mention of that.  I DON'T even see the DLL export
  246.  BS> ability.  And I know that they did something there...
  247.  BS> (* Even thought that's only available via protected mode *)
  248.  
  249. Try Chapter 11 of the Language Guide, "Dynamic-Link Libraries".
  250.  
  251.  
  252. --- Msg V3.2
  253.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  254.  
  255. --- RyPacker v2.5a
  256.  * Origin: RyBBS HomeBase  `Home of RyBBS!'  (414)-962-1098 (1:154/333)
  257.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:31:40
  258.  
  259. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  260.  
  261. Conference 4
  262. Date       03-02-93 08:08:00
  263. From       Dj Murdoch
  264. To         Wilbert Van Leijen
  265. Subject    Re: Functions Returning Strings
  266.  
  267.   DM> This isn't very safe programming. 
  268.  WV> You're right - you should treat this pointer to a 
  269.  WV> temporary string as a "constant" (read only) variable.  TP 
  270.  WV> has no provisions for this (yet) as far as function 
  271.  WV> results are concerned.  It's not that I want to put the 
  272.  WV> blame on the language or its definition - it's simply an 
  273.  WV> aspect I overlooked when I dreamt up this hack.
  274.  
  275. But it's not a constant - it's liable to change without any apparent action
  276.  by you. Try the example I sent:
  277.  
  278.   sp := StrPtr(Paramstr(1));
  279.   Saved := 'Parameter one: '+sp^; { This fails, and messes up Sp^. }
  280.  
  281. --- Msg V3.2
  282.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  283.  
  284. --- RyPacker v2.5a
  285.  * Origin: RyBBS HomeBase  `Home of RyBBS!'  (414)-962-1098 (1:154/333)
  286.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:31:43
  287.  
  288. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  289.  
  290. Conference 4
  291. Date       01-01-00 00:00:00
  292. From       
  293. To         
  294. Subject    
  295.  
  296.  
  297. --- WM v2.07/92-0445
  298.  * Origin: The Storm Front BBS - (215)788-4339 v.32b  (1:273/216)
  299.  * Tossed by SFToss/286 v1.02a on 93/03/05  09:32:37
  300.  
  301. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  302.  
  303. Conference 4
  304. Date       03-03-93 21:39:00
  305. From       Dj Murdoch
  306. To         Benjamin Schollnick
  307. Subject    Re: DLLs (was: rather foolish...)
  308.  
  309.   BS>     (* Ah, just found it....Replace Unit with Library, and
  310.  BS>     add 'export' to each procedure....They hid it *)
  311.  
  312.  BS>     But, what about *NON* protected mode app's?
  313.  
  314.  BS>     The DLL's only work with *PROTECTED* mode app's....I'm looking
  315.  BS>     for a similiar ability for NON-Protected mode app's.
  316.  
  317. Borland doesn't offer one.  I've been told that Topspeed Pascal has real mode
  318. .DLLs, but I've never come across anyone who actually uses it.
  319.  
  320. --- Msg V3.2
  321.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  322.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:40
  323.  
  324. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  325.  
  326. Conference 4
  327. Date       03-03-93 21:45:00
  328. From       Dj Murdoch
  329. To         Mitch Davis
  330. Subject    Re: tpu6->tpu7
  331.  
  332.   MD> I'm just wondering if it would be possible to read 
  333.  MD> in the old .TPU, add a sandwich to it, patch the places in 
  334.  MD> the old .TPU where parts of the old system unit was called 
  335.  MD> with the translator ruotines in the sandwich, and emit the 
  336.  MD> new code in the form that the .TPUs of the newer version 
  337.  MD> used.  Just an idea.
  338.  
  339. I think there's no question that it would be possible to write an updater,
  340. but it would be a lot of hard work.  Last time I estimated it I guessed 200
  341. hours, which probably really means 500.  If you've got that much spare time
  342. go for it.
  343.  
  344.  
  345.  
  346. --- Msg V3.2
  347.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  348.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:40
  349.  
  350. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  351.  
  352. Conference 4
  353. Date       03-03-93 22:06:00
  354. From       Dj Murdoch
  355. To         Matt J. Metzinger
  356. Subject    Re: Source code MANGLER
  357.  
  358.   MJ>      I've been thinking about writing a source code 
  359.  MJ> mangler.  Can you _OR ANYONE_ give me an idea of all the 
  360.  MJ> features that you would desire?
  361.  
  362. 1.  Strip comments.  2.  Remove all unnecessary white space.  3.  Convert
  363. all possible identifiers to random names like I010I1, with as many re-uses
  364. of the same identifier as possible.
  365.  
  366. Number 3 is the really hard one, because it means your program has to maintain
  367. a symbol table to know what substitutions to make, and has to understand scoping
  368. the same as the compiler so that it doesn't introduce errors when it recycles
  369. a name, and has to know about interfaced identifiers so that it doesn't change
  370. them.  
  371.  
  372. --- Msg V3.2
  373.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  374.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:40
  375.  
  376. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  377.  
  378. Conference 4
  379. Date       03-04-93 18:13:00
  380. From       Dj Murdoch
  381. To         Norbert Igl
  382. Subject    Re: Functions Returning Strings
  383.  
  384.   DM>   sp := StrPtr(Paramstr(1));
  385.  
  386.  NI>                   ^^  hmmmmm.....
  387.  
  388.  DM>   Saved := 'Parameter one: '+sp^; { This fails, and messes up Sp^. }
  389.  
  390.  NI>   typecasting a function...hmmmm
  391.  
  392. No, I'm just evaluating a function.  StrPtr is an inline function returning
  393. a pointer to its argument.  Here's Wilbert's declaration, from an earlier
  394. message:
  395.  
  396.  WV> Function StrPtr(Const s : String) : PString;
  397.  
  398.  WV> InLine(
  399.  WV>   $58/         { POP  AX }
  400.  WV>   $5A);        { POP  DX }
  401.  
  402. He presented this as an optimization; as my messages have said, it's not a
  403. reliable one.
  404.  
  405. --- Msg V3.2
  406.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  407.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:41
  408.  
  409. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  410.  
  411. Conference 4
  412. Date       03-04-93 18:26:00
  413. From       Dj Murdoch
  414. To         Norbert Igl
  415. Subject    Re: Fast Fourier Transformation...
  416.  
  417.   NI>   I'm searching for a quick FFT and inverse FFT ( in PAS or BASM )
  418.  NI>   for limiting the frequences in sound-samples.
  419.  
  420. There's one in Numerical Recipes by Press et al; that's what I use.  You can
  421. find an old version of the code in NRPAS???.ZIP; it's available at garbo.uwasa.f
  422.  in /pc/turbopas, and probably on PDN nodes on Fidonet.
  423.  
  424. --- Msg V3.2
  425.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  426.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:41
  427.  
  428. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  429.  
  430. Conference 4
  431. Date       03-04-93 18:50:00
  432. From       Dj Murdoch
  433. To         Hagen Lehmann
  434. Subject    Re: Making demos in TP 6.0
  435.  
  436.   HL> > There is a bug in TP 6.0 (fixed in 7.0) that causes the 
  437.  HL> Delay() procedure
  438.  HL> > to be inaccurate on some fast computers.  I don't have accurate code to
  439.  
  440.  HL> > fix it handy but someone in this echo should.
  441.  HL>  
  442.  HL> Nono, it is not fixed in 7.0 because 7.0 uses the old System-routines.
  443.  HL>  
  444.  HL> But here is a patch for 7.0:
  445.  
  446. I believe you're trying to help, but your post was very irresponsible, and
  447. may cause damage to some people's systems.   
  448.  
  449. 1. I haven't heard of any Delay trouble in 7.0, and Borland has claimed that
  450. the Delay bug is fixed.
  451.  
  452. 2. TP/BP 7.0 certainly don't use the old System or CRT routines.  There are
  453. lots of changes in there, including the Delay code.
  454.  
  455. 3. I'm not sure, but it looks to me as though your patch messes up something
  456. in the AssignCRT routine. 
  457.  
  458. In general, if you supply a patch, please provide both the bytes before and
  459. after the change and describe what it does.
  460.  
  461. Duncan Murdoch
  462. Moderator
  463.  
  464.  
  465. --- Msg V3.2
  466.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  467.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:41
  468.  
  469. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  470.  
  471. Conference 4
  472. Date       03-04-93 18:55:00
  473. From       Dj Murdoch
  474. To         Steve Connet
  475. Subject    Re: julian dating
  476.  
  477.   SC> Anyhow, here is the function ... please point out anything drastically
  478.  SC> wrong.
  479.  
  480.  SC> FUNCTION JulianDate(Y : Word; M, D : Byte) : Word;
  481.  SC> CONST Start = 1993;
  482.  SC>       Dm : Array [1..12] of Word =
  483.  SC>            (31,59,90,120,151,181,212,243,273,304,334,365);
  484.  SC> BEGIN
  485.  SC>   JulianDate := Dm[M-1]+D+(365*(Y-Start))+((Y-Start) Div 4)
  486.  SC> END;
  487.  
  488. You got the leap year correction wrong - it'll be wrong for all dates from
  489. March 1, 1996 to Dec 31, 1996.  You need to apply the leap day after Feb 28,
  490. not at the end of the year.
  491.  
  492.  
  493. --- Msg V3.2
  494.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  495.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:41
  496.  
  497. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  498.  
  499. Conference 4
  500. Date       03-04-93 20:20:00
  501. From       Dj Murdoch
  502. To         Karen Pivazyan
  503. Subject    Re: SIZES of variables, etc...
  504.  
  505.   KP> It doesn't matter if you use constants or actually type 
  506.  KP> them in, since values are substituted for constant's names 
  507.  KP> by preprocessor, before compiling.
  508.  
  509. Generally speaking, Pascal doesn't have a preprocessor.  The compiler handles
  510. constant declarations.  Certainly that's true of Turbo Pascal.
  511.  
  512. --- Msg V3.2
  513.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  514.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:41
  515.  
  516. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  517.  
  518. Conference 4
  519. Date       03-04-93 20:23:00
  520. From       Dj Murdoch
  521. To         Steve Connet
  522. Subject    Re: MOUSE
  523.  
  524.   SC>      writeln('MouseLib demo program, (c) 1992, Ron Loewy.'); 
  525.  
  526. I understand that you were trying to help, but please don't post code that
  527. belongs to other people.  
  528.  
  529. Duncan Murdoch
  530. Moderator
  531.  
  532.  
  533. --- Msg V3.2
  534.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  535.  * Tossed by SFToss/286 v1.02a on 93/03/06  11:37:41
  536.  
  537. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  538.  
  539. Conference 4
  540. Date       03-05-93 19:28:00
  541. From       Dj Murdoch
  542. To         Aaron Marasco
  543. Subject    Re: TPU <-> BIN/OBJ
  544.  
  545.   AM> Does anyone know of any way to convert a .TPU to a .BIN file to  
  546.  AM> use BIN2OBJ.EXE and then load it as an external? Any help  
  547.  AM> appreciated...  
  548.  
  549. That wouldn't help.  BIN2OBJ doesn't produce useful .OBJ files; it just sticks
  550. binary data into a file with a fake entry point at the start.
  551.  
  552. --- Msg V3.2
  553.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  554.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:11:41
  555.  
  556. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  557.  
  558. Conference 4
  559. Date       03-05-93 19:31:00
  560. From       Dj Murdoch
  561. To         Steve Connet
  562. Subject    Re: Date to LongInt
  563.  
  564.  JR>SC>  How do I convert a date string such as "19930227" to a LongInt?  JR>SC>
  565. The VAL command works only for Integers.  Thank you. 
  566.  JR>See the Lanquage Guide manual. It's on page p. 25 of 
  567.  SC> the BP/TP7 Language JR>Guide, and in a similar location for previous
  568. versions. 
  569.  
  570.  SC> Oh really?  Then how come it doesn't work?  Thanks for your reply. 
  571.  
  572. You must be doing something wrong.  It works for me:
  573.  
  574.  var
  575.   l : longint;
  576.   error : integer;
  577.   s : string;
  578.  begin
  579.   val('19930227',l,error);
  580.   if error = 0 then
  581.     writeln(l);
  582.  end.
  583.  
  584.  
  585. --- Msg V3.2
  586.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  587.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:11:41
  588.  
  589. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  590.  
  591. Conference 4
  592. Date       03-05-93 07:52:00
  593. From       Dj Murdoch
  594. To         Bernie Pallek
  595. Subject    Re: BUFFERS
  596.  
  597.   BP> To tell you the truth, I have never used New.  I 
  598.  BP> understand it's supposed to be OK, but I heard that GetMem 
  599.  BP> is better, because you can de-allocate memory without 
  600.  BP> having to use Mark and Release (or whatever those two are 
  601.  BP> called).  New doesn't look at the heap (I don't think it 
  602.  BP> does, at least), and it just grabs a chunk of memory.  
  603.  
  604. This is completely wrong.  The two statements
  605.  
  606.   New(p);
  607.  
  608. and
  609.  
  610.   Getmem(p, sizeof(p^));
  611.  
  612. are *exactly* equivalent.
  613.  
  614.  
  615. --- Msg V3.2
  616.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  617.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:12:52
  618.  
  619. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  620.  
  621. Conference 4
  622. Date       03-05-93 08:14:00
  623. From       Dj Murdoch
  624. To         Bbs Writers
  625. Subject    Bugs in your software
  626.  
  627.  The recent flood of messages from Greg Ryan's "ryBBS" shows a problem all too
  628. common in this echo:  software has bugs, and these bugs inconvenience all
  629. of us.  
  630.  
  631. This is a programmer's echo, so it's not surprising that a lot of different
  632. software is used here, but developers should take special care to limit the
  633. effect of their mistakes to their own system.  Besides simple consideration
  634. for others, think of the effect on your reputation of having your bugs spread
  635. around the world.
  636.  
  637. Duncan Murdoch
  638. Moderator
  639.  
  640. --- Msg V3.2
  641.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  642.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:12:52
  643.  
  644. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  645.  
  646. Conference 4
  647. Date       03-05-93 08:43:00
  648. From       Dj Murdoch
  649. To         All
  650. Subject    March 93 Guidelines for the PASCAL echo
  651.  
  652.  First, a short summary of the rules:
  653.  
  654.  o The topic is Pascal, in any form on any platform.  Stay on topic!
  655.  o Try to make your messages be of interest to as many people as possible;
  656.    personal messages are always off-topic.
  657.  o Leave moderation to the moderator.
  658.  o NO FLAMING!
  659.  o If you post untested code, make that clear.  It's better to test it first,
  660.    though.
  661.  o Religion, politics, copyright, and illegal activities are all off-topic.
  662.  o Try to work out your problem by yourself, first.  If you can't get the 
  663.  
  664.    answer, then spend some time writing your question clearly.
  665.  o Try to give answers in as helpful a way as possible.
  666.  o All code posted should be public domain or specifically released for 
  667.    non-profit use and distribution by the copyright holder.
  668.  o Keep origin lines less than 79 characters, tear lines less than 25 
  669.    characters, and messages less than 16K in length.
  670.  o The moderator is DJ Murdoch, at 1:249/99.5.
  671.  o The full list of rules is posted monthly.
  672.  
  673. To all sysops:
  674.  
  675. Would all sysops please ensure that a copy of these guidelines is available
  676. to all users of the PASCAL echo.  I'd suggest cutting out the summary above
  677. and having it print when users enter the PASCAL area of your BBS. You might
  678. also make this a protected message to ensure that normal message area housekeepi
  679. g does not not result in its being deleted.  I try to re-post these guidelines
  680. every month. 
  681.  
  682.  Duncan Murdoch
  683.  Pascal Moderator
  684.  
  685. GUIDELINES FOR THE PASCAL ECHO - THE DETAILS
  686.  
  687. The Pascal echo is an internationally distributed FidoNet echo devoted to
  688. the discussion and promotion of the Pascal programming language in all its
  689. variations.
  690.  
  691. MODERATOR.
  692.  
  693. The current moderator is Duncan Murdoch. I can be reached by Netmail at 1:249/99
  694. 5; by Compuserve mail to 71631,122; by Internet mail to dmurdoch@mast.queensu.ca
  695. or by normal postage by writing to -
  696.  
  697.   Duncan Murdoch
  698.   337 Willingdon Ave.
  699.   Kingston, Ontario, Canada
  700.   K7L 4J3
  701.  
  702.  
  703. GUIDELINES.
  704.  
  705.  1. Leave moderation to the moderator. Self appointed "echo policemen"
  706.     only waste echo space and create ill-feeling.
  707.  
  708.  2. NO FLAMING. If you feel that you have been insulted in some way by
  709.     somebody, you have three options.
  710.      (a) Complain by netmail to the person concerned.
  711.      (b) Bring the matter to the moderator's notice - again by netmail.
  712.      (c) Ignore it. (the preferred option!)
  713.  
  714.  3. Person-person messages that are not of general interest to other
  715.     users are STRICTLY not permitted. Netmail these types of messages.
  716.  
  717.  4. When replying to messages try to do so "off-line" and quote some of
  718.     the message being replied to, but don't go overboard with quoting.
  719.     Quote just enough to enable the context of the reply to be fully
  720.     understood and in particular DO NOT INCLUDE PARTS OF THE TEAR AND
  721.     ORIGIN LINES.
  722.  
  723.     Try reading over your reply before you commit yourself to sending
  724.     it.  Try to anticipate the first question readers will ask, and add
  725.     the answer to your message.
  726.  
  727.  5. When replying to questions with code examples, test them where
  728.     possible by compiling and running them (or state that you have not
  729.     done this). If possible always quote manual references, text
  730.     references etc.
  731.  
  732.  6. If replying to a question where you are disagreeing with the other
  733.     person's code or statement/s, support your viewpoint with working
  734.     code examples or valid text references. This will be more productive
  735.     than unsupported statements. If you are not prepared to do this then
  736.     don't reply in the first place!
  737.  
  738.  7. Do not ENTER or REPLY TO off-topic messages. The subject matter is
  739.     Pascal.  Discussions on religion, politics, copyright, other
  740.     languages and personal messages are OFF-TOPIC.  Any subject that is
  741.     illegal or undesirable in a responsible conference - eg discussion or
  742.     tips on producing viruses or how to illegally obtain access to
  743.     information that the user is unauthorised to obtain, is off-topic.
  744.  
  745.     Sometimes messages from other conferences become linked into another
  746.     conference due to faulty software. Replying to, or commenting on, such
  747.     messages is off-topic.
  748.  
  749.     The main point is to use common sense.  Some light hearted banter can
  750.     relieve the formality and brighten up one's day but do not carry this to
  751.  
  752.     the length where it becomes an extended thread.  The object of the echo
  753.     is to help, get help and enjoy communicating with like-minded people.
  754.  
  755.  8. No "thank-you" or "no content" or "rubbish" messages. Sysops spend a
  756.     great deal of time and money to enable the distribution of echoes
  757.     such as this. Please respect this and avoid messages such as "Thank
  758.     you. Just what I needed" or "I agree" etc. By observing this
  759.     etiquette you will be helping to ensure greater participation in the
  760.     future.  If you miss a message or code for some reason, make your
  761.     own private arrangements to get it. Repeated postings of code are
  762.     expensive and unnecessary.
  763.  
  764.  9. All messages are to be in the English language and must be in PLAIN
  765.     TEXT.  No encryption of any kind is permissible. As the aim of the
  766.     conference is to help, discuss and demonstrate the Pascal language,
  767.     no .OBJ, .EXE or .COM files of any description are permitted
  768.     REGARDLESS of how they be constructed.  The echo is NOT to be
  769.     regarded as a file transfer or exchange channel.
  770.  
  771. 10. Limited, low key, on-topic advertising is permitted, provided that it
  772.     is authorised by the sysop of the originating BBS and by the
  773.     Moderator BEFORE it is posted here.
  774.  
  775. 11. When seeking assistance -
  776.     a)  If Turbo Pascal is your language, place the cursor on the key
  777.         word and call the on-line help (Ctrl-F1 in the IDE) to see if
  778.         the answer may be there.
  779.     b)  Double check the manual to see if the answer is there.
  780.     c)  When writing the message include enough code to allow would-be
  781.         helpers to have a chance to determine what the problem might be.
  782.         If possible condense the problem into a tiny working example and
  783.         post that.
  784.     d)  This is a high volume echo so use a subject line in the message
  785.         that is likely to gain attention from the experts who are often
  786.         too busy to read every message.  "Help wanted" or similar is a
  787.         good way to be ignored. Something like "Exec procedure not
  788.         working" is better.
  789.     e)  Remember that a reply of "RTFM" is not considered or meant as an
  790.         insult. In fact it is considered a polite (in spite of the
  791.         connotations) way of reminding someone that the answer they seek
  792.         is in the manual.
  793.     f)  Remember also that your reply may come from anyone, of possibly
  794.         unknown skill level.  Don't be too upset if misled as it is
  795.         probably unintentional and will almost certainly be corrected by
  796.         another reader.
  797.     g)  Many BBSs carry a file - FAQ.TXT (or similar) - which contains the
  798.         answers to frequently asked questions.
  799.     h)  The PDN has a file TCSEL*.ARJ that contains many useful routines
  800.         that the previous moderator posted in the echo over the years. This
  801.         file also contains a file A2FAPQ.TXT which answers many commonly
  802.         asked questions.
  803.  
  804. 12. When offering advice or help -
  805.     a)  Do so in a helpful, polite manner.  Don't be condescending - not
  806.         everybody may have your experience or skills.
  807.     b)  Refer to the page in the manual where the answer is if your
  808.         answer is "RTFM"!
  809.  
  810. 13. Messages should comply with the FidoNet message requirements. Origin
  811.     lines should not exceed 79 characters, tear lines must not exceed 25
  812.     characters and messages should not contain extended "internet" style
  813.     signatures. No encrypted text is permitted. Messages must be <16K.
  814.  
  815. 14. All code posted should be public domain if possible.  No copyrighted
  816.     code may be posted unless the copyright owner included permission for
  817.     non-profit reproduction and use in the original code. Code posted
  818.     without copyright claim will be regarded as in the Public Domain.
  819.  
  820. 15. Election of Moderator.  Under a normal situation, if the moderator
  821.     wishes to step aside, s/he will appoint a new moderator taking into
  822.     account the wishes of the regular users where possible.  In the event
  823.     of a moderator ceasing to participate in the echo for a period of
  824.     three months without prior notice being given of the absence, for
  825.     whatever reason, then the ZEC (1:1/201) will conduct, or nominate a
  826.     regular and senior echo participant to conduct, an election for a new
  827.     moderator.
  828.  
  829.  
  830. --- Msg V3.2
  831.  * Origin: Murdoch's_Point  - -   (1:249/99.5)
  832.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:12:53
  833.  
  834. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  835.  
  836. Conference 4
  837. Date       03-05-93 19:40:00
  838. From       Norbert Igl
  839. To         J J Marquez
  840. Subject    Screen Print from PASCAL
  841.  
  842.  
  843.  
  844. Hello J!
  845.  
  846. One of these days, J J Marquez wrote to All'y'all:
  847.  
  848.  JJM>    How would I get a Turbo Pascal program to cause a screen print to
  849.  JJM> happen?
  850.  
  851.  (:-))))       Inline( $cd/ $05 );
  852.  
  853.  
  854. Norbert
  855.  
  856. --- GoldEd 2.40p/FD2.02/FastEcho
  857.  * Origin: mother's finest. (:-)  (2:2402/300.3)
  858.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:12:56
  859.  
  860. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  861.  
  862. Conference 4
  863. Date       03-05-93 23:34:00
  864. From       Norbert Igl
  865. To         Dj Murdoch
  866. Subject    Functions Returning Strings
  867.  
  868.  
  869.  
  870. Hello Dj!
  871.  
  872. One of these days, Dj Murdoch wrote to Norbert Igl:
  873.  
  874.  DM>> sp := StrPtr(Paramstr(1));
  875.  
  876.  NI>> ^^  hmmmmm.....
  877.  
  878.  DM>> Saved := 'Parameter one: '+sp^; { This fails, and messes up Sp^. }
  879.  
  880.  NI>> typecasting a function...hmmmm
  881.  
  882.  DM> No, I'm just evaluating a function.  StrPtr is an inline function returning
  883.  
  884.   ahhh.. i missed that point.
  885.  
  886.  DM> a pointer to its argument.  Here's Wilbert's declaration, from an earlier
  887.  DM> message:
  888.  WV>> Function StrPtr(Const s : String) : PString;
  889.  
  890.  WV>> InLine(
  891.  WV>> $58/         { POP  AX }
  892.  WV>> $5A);        { POP  DX }
  893.  
  894.  DM> He presented this as an optimization; as my messages have said, it's not a
  895.  
  896.  DM> reliable one.
  897.  
  898.  ...even worse, "StrPtr" reads like a type's name , not a function.
  899.   Str2Ptr would have been better .... i would'nt have mixed it up !
  900.  
  901.   Norbert
  902.  
  903. --- GoldEd 2.40p/FD2.02/FastEcho
  904.  * Origin: Fly like an Igl  (2:2402/300.3)
  905.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:12:56
  906.  
  907. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  908.  
  909. Conference 4
  910. Date       03-05-93 23:31:00
  911. From       Norbert Igl
  912. To         Dj Murdoch
  913. Subject    Fast Fourier Transformation...
  914.  
  915.  
  916.  
  917. Hello Dj!
  918.  
  919. One of these days, Dj Murdoch wrote to Norbert Igl:
  920.  
  921.  NI>> I'm searching for a quick FFT and inverse FFT ( in PAS or BASM )
  922.  NI>> for limiting the frequences in sound-samples.
  923.  
  924.  DM> There's one in Numerical Recipes by Press et al; that's what I use.  You
  925.  
  926.  DM> can find an old version of the code in NRPAS???.ZIP; it's available at
  927.  DM> garbo.uwasa.fi in /pc/turbopas, and probably on PDN nodes on Fidonet.
  928.  
  929.  I found NRPAS13.* nearby... thanks !
  930.  
  931.  
  932. Norbert
  933.  
  934. --- GoldEd 2.40p/FD2.02/FastEcho
  935.  * Origin: Fly like an Igl  (2:2402/300.3)
  936.  * Tossed by SFToss/286 v1.02a on 93/03/07  02:12:57
  937.